Distributing network path information in a network environment

ABSTRACT

Methods for distributing multicast network path information to various network nodes in a network environment are disclosed. An exemplary method includes a downstream node transmitting a first message including a network path indicating a specific desired route that is to be used when delivering multicast traffic from a given multicast source to a given host, as well as an identifier assigned to the network path in order to uniquely identify that network path in the network. The method also includes the downstream node transmitting a second message for announcing that the multicast source is to be reached via the network path announced in the first message. The second message identifies the network path to be used by including the identifier of the path announced in the first message, but not the network path itself.

TECHNICAL FIELD

This disclosure relates in general to the field of communications and,more particularly, to systems and methods for distributing network pathinformation in a network environment.

BACKGROUND

Networking architectures have grown increasingly complex incommunication environments. A typical network environment contains amyriad of network nodes, including hosts, load balancers, routers,switches, etc. These network nodes support propagation of data packetsfrom sources to destination hosts. Improving operational efficiency andoptimizing utilization of resources in such network environments aresome of the challenges facing their managers. One such challenge arisesfrom a fact that, often times, in a typical network environment, e.g. ina service provider network, various network nodes have varyingcharacteristics in terms of bandwidth, latency, fault tolerance, legalrequirements, etc. Because of this, it may be desirable to have controlover which network paths are traversed by data packets sent by sources,a process known as a “path selection.” Path selection allows selecting asequence of specific network nodes within a network environment forforwarding traffic from a given source to one or more destination hostsin an attempt to optimize performance and resilience requirements.Efficient distribution of network path information to all network nodesinvolved is desired by network operators, service providers, and endusers alike.

BRIEF DESCRIPTION OF THE DRAWINGS

To provide a more complete understanding of the present disclosure andfeatures and advantages thereof, reference is made to the followingdescription, taken in conjunction with the accompanying figures, whereinlike reference numerals represent like parts, in which:

FIG. 1 is a simplified block diagram illustrating a conventionalapproach to distributing network path information in a networkenvironment using PIM join/prune messages;

FIG. 2 is a simplified block diagram illustrating an exemplary networkenvironment configured to distribute network path information using pathlist messages and PIM join/prune messages, according to some embodimentsof the present disclosure;

FIG. 3A illustrates an example of a conventional PIM join/prune messagefor announcing one or more paths to one or more sources;

FIGS. 3B and 3C illustrate, respectively, a path list message and a PIMjoin/prune message for announcing one or more paths to one or moresources, according to some embodiments of the present disclosure;

FIG. 4A illustrates an example of a conventional PIM join/prune messagefor announcing one path to one source;

FIGS. 4B and 4C illustrate, respectively, a path list message and a PIMjoin/prune message for announcing one path to one source, according tosome embodiments of the present disclosure;

FIG. 5 is a simplified block diagram illustrating an exemplary networkenvironment configured to distribute network path information using pathlist messages and PIM join/prune messages in which a single pathidentifier can be used for multiple sources, according to someembodiments of the present disclosure;

FIG. 6A illustrates an example of a conventional PIM join/prune messagefor announcing the same path to multiple sources;

FIGS. 6B and 6C illustrate, respectively, a path list message and a PIMjoin/prune message for announcing the same path to multiple sources,according to some embodiments of the present disclosure;

FIG. 7 is a simplified block diagram illustrating an exemplary networkenvironment configured to distribute network path information using pathlist messages and PIM join/prune messages in which multiple paths andtheir path identifiers can be announced in a single path list message,according to some embodiments of the present disclosure;

FIG. 8A illustrates an example of conventional PIM join/prune messagesfor announcing different paths to sources;

FIGS. 8B and 8C illustrate, respectively, a path list message and PIMjoin/prune messages for announcing different paths to sources, accordingto some embodiments of the present disclosure;

FIG. 9 is a simplified block diagram illustrating an exemplary networkenvironment configured to distribute updated network path informationusing path list messages and PIM join/prune messages, according to someembodiments of the present disclosure;

FIG. 10A illustrates an example of conventional PIM join/prune messagesfor announcing a path update;

FIGS. 10B and 10C illustrate, respectively, a path list message and PIMjoin/prune messages for announcing a path update, according to someembodiments of the present disclosure;

FIG. 11 is a flow diagram of a method for distributing network pathinformation using path list messages and PIM join/prune messages,according to some embodiments of the present disclosure;

FIG. 12 illustrates an example network device suitable for implementingvarious embodiments of the present disclosure; and

FIGS. 13 and 14 illustrate example systems suitable for implementingvarious embodiments of the present disclosure, according to someembodiments of the present disclosure.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

Embodiments of the present disclosure provide methods for distributingnetwork path information, in particular for distributing multicast pathselection information, to various network nodes in a networkenvironment. In one aspect of the present disclosure, an exemplarymethod includes a downstream network node generating and transmitting afirst message that includes a network path indicating a specific desiredroute that is to be used when delivering multicast traffic from a givenmulticast source to a given host. The network path specifies a sequenceof one or more intermediate network nodes between a downstream nodecommunicatively connected to the host and an upstream nodecommunicatively connected to the multicast source which are to betraversed when forwarding multicast traffic from the source to the host.In addition, the first message includes an identifier assigned to thenetwork path in order to uniquely identify that network path in thenetwork. The method also includes the downstream node generating andtransmitting a second message for announcing that the multicast sourceis to be reached via the network path announced in the first message.The second message identifies the network path to be used by includingthe identifier of the path announced in the first message, but not thenetwork path itself (i.e. not the sequence of nodes).

The first message as described above is a new type of message proposedherein and is referred to in the following as a “path list message.” Thesecond message as described above can e.g. be aprotocol-independent-multicast (PIM) join/prune message. Conventionally,PIM join/prune messages carried both the identification of a multicastsource to which the message relates and a network path from the sourceto the host. One problem with such conventional implementations is thatPIM join/prune messages can potentially get very large, due to theencoding of explicit paths, necessitating the use of additional PIMjoin/prune messages to convey the network path information. Furthermore,in case there are changes to a path, all of the PIM join/prune messageshave to be re-sent, carrying the updated path information to all of thenetwork nodes in the updated path, and each network node in the updatedpath will have to re-process the message. In contrast to suchconventional implementations, using the identifier of a network path insuch messages, instead of the network path itself, and sending theexplicit network path information in a separate message, as proposed inthe present disclosure, advantageously allows reducing the number ofmessages traversing the network.

In the following detailed description, various aspects of theillustrative implementations will be described using terms commonlyemployed by those skilled in the art to convey the substance of theirwork to others skilled in the art. For example, the term “multicastsource” (sometimes interchangeably referred to as a “multicast sourcedevice” or simply as a “source”) refers to any computing/storage devicethat functions as a source of distributing multicast content, while theterm “host” (sometimes interchangeably referred to as a “destination”, a“receiver,” a “host device,” or a “customer/client device”) refers toany computing/storage device that consumes multicast content. In variousembodiments, a “host” may be or may include, by way of non-limitingexample, any device providing storage, network, or/and computingresource in a network environment. Examples of hosts include, but arenot limited to, a laptop computer, cellular telephone, IP telephone,smart phone, tablet computer, convertible tablet computer, server,computer, workstation, mainframe, virtual machine (whether emulated oron a “bare-metal” hypervisor), container, embedded computer, embeddedcontroller, embedded sensor, personal digital assistant, computingappliance, network appliance, receiver, wearable computer, handheldcalculator, or any other electronic, microelectronic, ormicroelectromechanical device for processing and communicating data. Asused herein, the term “network node” (sometimes interchangeably referredto as a “network element,” “node,”, or ““network device”) is meant toencompass routers, switches, gateways, bridges, computers, processors,servers, network appliances, modules, cable boxes, load balancers,firewalls, inline service nodes, proxies, or any other suitable device,component, element, or proprietary appliance operable to exchangeinformation in a network environment in accordance with embodimentsdescribed herein. Network nodes described herein may include anysuitable hardware, software, components, modules, or interfaces thatfacilitate the operations thereof, and may be inclusive of appropriatealgorithms and communication protocols that allow for the effectiveexchange of data or information. The terms “upstream” and “downstream”as used herein refer to the flow of traffic from a source to a receiver.An “upstream network node” (or simply an “upstream node”) refers to aningress node that the source is communicatively connected to (i.e. anetwork node through which the source injects traffic into the network).A “downstream network node” (or simply a “downstream node”) refers to anegress node that the host is communicatively connected to (i.e. anetwork node through which the traffic is ejected from the network andprovided to further devices, e.g. to a receiver). Network nodes mayoperate as both upstream and downstream nodes for different trafficflows.

As will be appreciated by one skilled in the art, aspects of the presentdisclosure, in particular a functional entity performing embodiments ofthe methods described herein, may be embodied in various manners.Accordingly, various aspects of the present disclosure relate tosystems, computer programs, mechanisms, and means for carrying out themethods according to various embodiments described herein. Such systems,computer programs, mechanisms, and means could be included withinvarious network nodes, such as e.g. switches and routers, of a networkenvironment, or distributed among a plurality of network nodes. Acomputer program may, for example, be downloaded (updated) to theexisting network devices and systems (e.g. to the existing routers,switches, various control nodes within a network environment, etc.) orbe stored upon manufacturing of these devices and systems.

In yet another aspect, the present application relates to one or morenon-transitory computer readable storage media encoded with softwarecomprising computer executable instructions and, when executed by aprocessor of a computer, operable to carry out the method according tovarious embodiments described herein.

In yet another aspect, the present application relates to various datastructures to be used in messages exchanged within a networkenvironment. In one embodiment, such a data structure may be includedwithin PIM update messages. In another embodiment, such a data structuremay be included within path list messages proposed herein.

Example Embodiments

For purposes of illustrating certain example techniques for distributingnetwork path information in a network environment described herein, itis important to understand the communications that may be traversing thenetwork. The following foundational information may be viewed as a basisfrom which the present disclosure may be properly explained. Suchinformation is offered for purposes of explanation only and,accordingly, should not be construed in any way to limit the broad scopeof the present disclosure and its potential applications.

As the subscriber base of end users increases, proper routing andefficient management of communication sessions and data flows becomescritical. Internet Protocol (IP) communications generally providedifferent types of communication methods across a network, e.g. unicastand multicast.

Unicast is a method of point-to-point communication, and it is typicallyused when two nodes need to exchange data, where neither node isconcerned with sharing the data with multiple hosts (also referred to as“destinations”). In unicast routing, unicast data, in the form ofunicast packets, is sent from a single source to a single host (i.e. asingle destination). The packets are routed by network devices, such asrouters, towards a destination address (typically an IP address) of thedesired host. The source address of a unicast packet plays little or nopart in routing of unicast data, with the unicast packets being routedbased on their destination address.

Multicast is a method of sending data over a computer network from asingle source to multiple hosts. Multicast communications can allow acertain group of hosts to receive messages without having to broadcastthose messages to all of the hosts in the broadcast domain.

Multicast is a bandwidth-conserving technology that reduces traffic in anetwork by simultaneously delivering data to multiple select hosts. Tothat end, multicast leverages the concept of a group, where a multicastgroup is an arbitrary group (G) of hosts that express an interest inreceiving a particular data stream from a source (S), e.g. to view aparticular channel of an Internet-based television program provider. Inmulticast routing, multicast data, in the form of multicast packets, issent from a source (S) address to a multicast group (G) address that iscommon to the hosts in the group. Hence, any multicast transmission hasa multicast group address, G. A multicast group can receive data frommore than one source, and each such source can also have a regular(class A, B, and C) internet address (S). The notation (*, G) generallymeans every possible source for a given group G, while the notation (S,G) means a particular source, at a particular Internet address S, for agiven group G. Hosts which are members of a given multicast group canreceive multicast data sent to that group.

A host seeking to receive data sent to a multicast group can join thegroup using, for example, Internet Management Group Protocol (IGMP), aprotocol used by hosts and by multicast-enabled routers to form andmanage multicast groups. To join a group, a host typically sends an IGMPmembership report, also referred to as an “IGMP join” message, to alocal multicast router associated with the host, the local multicastrouter commonly referred to as a “downstream router” or, more generally,as a “downstream node.” The membership report can indicate to thedownstream node that the host is interested in joining a particularmulticast group. The address of the multicast group is often included inthe membership report because the address is indicative of whichmulticast data the host is interested in receiving. The downstream node,recognizing that the host wishes to join the group, establishes a pathfrom a remote router associated with the source, the remote multicastrouter commonly referred to as an “upstream router” or, more generally,as an “upstream node,” to itself (i.e. to the downstream node), and thenforwards received multicast data to the host accordingly.

In unicast routing, traffic is routed through the network along a singlepath from the source to the destination host. A unicast router isindifferent to the source address; it only evaluates the destinationaddress and how to forward the traffic toward that destination. Therouter typically scans through its routing table, and then forwards asingle copy of the unicast packet out of the correct interface in thedirection of the destination. In multicast routing, the source issending traffic to an arbitrary group of hosts represented by amulticast group address. The multicast router determines which directionis upstream (toward the source) and which direction (or directions) isdownstream. If there are multiple downstream paths, the routerreplicates the packet and forwards the traffic down the appropriatedownstream paths. This concept of identifying the path to reach thesource, in order to get the traffic from the source via the same path,is known as reverse path forwarding (RPF). RPF is a fundamental conceptin multicast routing that enables routers to correctly forward multicasttraffic down the distribution tree. RPF makes use of the existingunicast routing table to determine the upstream and downstreamneighbors. A router can forward a multicast packet when it is receivedon an upstream interface.

The term Live-Live (also referred to as Hot-Hot) offers a method ofsending redundant data streams through the network using path separationand dedicated infrastructure. For example, an A copy of the streamswould be sent to one set of multicast groups and a B set of streamswould be sent using a second set of multicast groups. Each of thesegroups will theoretically be delivered using a parallel, but a separate,set of equipment to the end user with physical path separation.

Protocol-independent multicast (PIM) is a family of multicast routingprotocols for IP networks that provide one-to-many and many-to-manydistribution of data over a local area network (LAN), a wide areanetwork (WAN), or the Internet. PIM gets its name from the fact that itis independent of any specific IP routing protocol because it does notinclude its own topology discovery mechanism, but instead uses routinginformation supplied by other routing protocols. PIM can leverage theunicast routing protocols being used to populate the unicast routingtables. PIM uses this unicast routing information to perform themulticast forwarding function and, thereby, makes the mechanismprotocol-independent. Although PIM is called a multicast routingprotocol, it can use the unicast routing table to perform the RPF checkfunction, instead of building a completely independent multicast routingtable.

PIM allows distributing network path information and connecting thenetwork nodes in a given path by employing so-called PIM join/prunemessages. Conventional implementation of PIM is illustrated in FIG. 1showing a schematic illustration of a network environment 100.

As shown in FIG. 1, a network within the network environment 100includes a plurality of network nodes, shown as network nodes R1-R7 andnetwork nodes R22-R55. Illustration, in FIG. 1, of a host H1 beingconnected to the node R1 is intended to indicate that the node R1 is adownstream node (i.e. the egress node associated with the host H1). Onthe other hand, illustration of a source S0 being connected to the nodeR6 is intended to indicate that the node R6 is an upstream node (i.e.the ingress node associated with the source S0). Links within variousnetwork nodes shown in FIG. 1 are intended to illustrate various pathsbetween the downstream node R1 and the upstream node R6.

Consider that the host H1 sends an IGMP join message 102 to thedownstream node R1, indicating that the host wants to join a certainmulticast group G. Consider also that the path from the downstreamrouter R1 to the upstream router R6 is e.g. a path {R2, R3, R4, R5, R6}.In various embodiments, e.g. one of dynamic computation methods at thedownstream router or static configuration of the downstream router (e.g.by a network operator) may be responsible for determining the path. FIG.1 illustrates that, in conventional implementations, in order to set upthis specified path for providing requested multicast traffic from thesource S0 to the host H1, the downstream router R1 will send a PIMjoin/prune message to the first node in the sequence of nodes specifiedby the path (i.e. to the RPF neighbor for the downstream router R1 inthe sequence of nodes specified by the path). In the exemplary sequence{R2, R3, R4, R5, R6}, that would be the node R2, and FIG. 1 illustratesa PIM join/prune message 104 being sent from R1 to R2. Such a messagewould include an identification of a multicast group that host H1indicated the desire to join, an identification of a source which canprovide requested multicast traffic (i.e. S0), and a complete path list{R2, R3, R4, R5, R6}, i.e. a sequence of nodes from the downstream nodeto the upstream node.

Each network node typically includes interfaces, fabric card modules,and programming logic. The interfaces are configured to receive and sendmulticast packets. The fabric card modules are configured to providehigh-speed data forwarding connectivity for the interfaces within thenetwork node. The programming logic is configured to implementprogramming of multicast entries in the node and may further beconfigured to implement the functionality of network path distributionas described herein.

Upon receiving such a PIM join/prune message, node R2 will create (S0,G) forwarding entry in its multicast forwarding table. Such a forwardingentry would contain a field containing an identification of an upstreaminterface of R2 to be used for receiving multicast traffic and one ormore fields containing identifications of one or more downstreaminterfaces of R2 to be used for forwarding the received multicasttraffic in order to get the traffic to host H1 via the path specified inthe PIM join/prune message. Example interfaces are shown as interfaces1220 of an exemplary system, e.g. any of the network nodes of FIG. 1,configured to perform embodiments of the present disclosure, shown inFIG. 12 and described in greater detail below. For this example, R2 willconfigure an interface to node R3 as an upstream interface for receivingmulticast traffic destined to the host H1 (because R3 is the next node,from R2, in the sequence) and will configure an interface to node R1 asa downstream interface for forwarding the multicast traffic destined tohost H1 (because R1 is the node that immediately precedes node R2 in thesequence {R2, R3, R4, R5, R6}). R2 will further determine whether it isthe upstream node for the received path. In the example illustrated, R2is not the upstream node and, therefore, R2 will re-originate anotherPIM join/prune message and send it to the next node in the sequence ofnodes specified by the path (i.e. to the RPF neighbor for the node R2 inthe sequence of nodes specified by the path). In the exemplary sequence{R2, R3, R4, R5, R6}, that would be the node R3, and FIG. 1 illustratesa PIM join/prune message 104 being sent from R2 to R3. All of thesubsequent nodes, i.e. R3-R6 in this example, will perform thefunctionality as described for R2. In this manner, the PIM join/prunemessages will propagate through the network from the downstream node tothe upstream node in accordance to the specified path, configuring eachnode in the path to forward multicast traffic from the source S0 to thehost H1 also in accordance with the specified path, i.e. upstream nodeR6 will forward multicast traffic received from the source S0 anddestined for the multicast group requested by the host H1 to node R5, R5will forward the traffic received from R6 to R4, and so on.

If there is a change in the path that was previously specified, e.g. anupdated path between the downstream node R1 and the upstream node R6should now be {R2, R3, R4, R7, R6}, i.e. node R5 is replaced by node R7,then the PIM join/prune messages carrying the updated path are re-sentby each of the nodes involved, starting with the downstream node R1.Each node receiving a PIM join/prune message with updated pathinformation will re-process the entire message in the manner describedabove and re-send the message to join with the subsequent nodes, inaccordance with the updated path.

Each node receiving a PIM join/prune message will also determine whetherany of the previously established connections for carrying the multicasttraffic from S0 to H1 are to be pruned (i.e. eliminated), as known inthe art. In this example, node R4 will determine that connection to R5is to be pruned and a new connection, to R7, is to be established.Therefore, R4 will send a PIM join/prune message to node R7 initiatingcreation of a link between R4 and R7 and will send a PIM join/prunemessage to R5 initiating pruning of a link between R4 and R5.

As described above, such a conventional implementation is problematicbecause PIM join/prune messages can, and often do, get very large due tothe encoding of explicit paths, and, if there are changes to a path, allof the PIM join/prune messages have to be re-sent and re-processed byeach of the network nodes involved even though the change may not affectthose nodes. For example, a change from a path {R2, R3, R4, R5, R6} to apath {R2, R3, R4, R7, R6} does not affect multicast traffic forwardingof nodes R3, R2, and R1 because, for both the original and the updatedpaths, these nodes receive multicast traffic from the same upstreaminterface (in this example—R3 receives multicast traffic from theupstream interface to node R4, R2 receives multicast traffic from theupstream interface to node R3, and R1 receives multicast traffic fromthe upstream interface to node R2) and forward the received multicasttraffic on the same downstream interface (in this example—R3 forwardsmulticast traffic via the downstream interface to node R2, R2 forwardsmulticast traffic via the downstream interface to node R1, and R1forwards multicast traffic via the downstream interface to host H1).

Embodiments of the present disclosure aim to reduce wasteful use ofprocessing resources and bandwidth in a network environment describedabove by using identifiers of network paths and using new path listmessages and PIM join/prune messages carrying the identifiers instead ofthe explicit paths, as will now be described in greater detail.

FIG. 2 is a simplified block diagram illustrating an exemplary networkenvironment 200 configured to distribute network path information usingpath list messages and PIM join/prune messages, according to someembodiments of the present disclosure.

The network environment 200 shown in FIG. 2 is merely one example inwhich embodiments of the present disclosure may be implemented, namelyan example illustrating a particular number of network nodes andparticular connections between these nodes. Thus, while the networkenvironment 200 shown in FIG. 2 illustrates a certain number of sources,a certain number of hosts, a certain number of network nodes, andcertain connections between sources, hosts, and network nodes,embodiments of the present disclosure are applicable to any number ofsources, hosts, and network nodes, and any connections between those.Furthermore, while described with reference to PIM, a skilled personwill readily recognize that teachings provided herein are equallyapplicable to other protocols and other network architectures anddeployments, and may be used with messages similar to but not limited toPIM, all of which being within the scope of the present disclosure.

The network environment 200 shown in FIG. 2 represents a series ofpoints or nodes of interconnected communication paths for receiving andtransmitting packets of information that propagate through the networkenvironment. The network environment 200 offers a communicativeinterface between nodes (e.g., various network elements within the TOR,etc.), and may include any type or topology of one or more networks suchas a local area network (LAN), wireless local area network (WLAN),metropolitan area network (MAN), virtual local area network (VLAN),Intranet, Extranet, wide area network (WAN) such as the Internet,virtual private network (VPN), any other appropriate networkconfiguration, or any suitable combination thereof that facilitatescommunications in the network environment 200. Network nodes of thenetwork environment 200 may include any number of hardware or softwareelements coupled to (and in communication with) each other through acommunications medium. Elements of FIG. 2 may be coupled to one anotherthrough one or more interfaces employing any suitable connections (wiredor wireless), which provide viable pathways for network communications.Additionally, one or more of these elements may be combined, divided, orremoved from the architecture based on particular configuration needs.For ease of illustration, not all elements of FIG. 2 are depicted withcommunication lines traversing the network environment 200.

In the network environment 200, network traffic, which could includepackets, frames, signals, cells, datagrams, protocol data units (PDUs),data, etc., can be sent and received according to any suitablecommunication messaging protocols. Suitable communication messagingprotocols can include a multi-layered scheme such as Open SystemsInterconnection (OSI) model, or any derivations or variants thereof(e.g., Transmission Control Protocol/Internet Protocol (TCP/IP), userdatagram protocol/IP (UDP/IP)). A packet is a unit of data forcommunicating information in a network, and can be routed between asource node and a destination node via a network. A packet may include,but is not limited to, a source network address, a destination networkaddress, and a payload containing the information/data to becommunicated. By way of example, these network addresses can be InternetProtocol (IP) addresses in a TCP/IP messaging protocol. Information isgenerally represented by data and, as used herein, ‘data’ refers to anytype of binary, numeric, voice, video, media, textual, or script data,or any type of source or object code, or any other suitable informationin any appropriate format that may be communicated from one point toanother in electronic devices and/or networks.

Comparison of FIGS. 1 and 2 reveals that the network environments 100and 200 are very similar. Indeed, unless explained otherwise, theexplanations provided above for FIG. 1 are applicable to the networkenvironment 200 and, therefore, in the interests of brevity, are notrepeated.

As shown in FIG. 2, in the network environment 200, downstream nodes,such as e.g. the downstream node R1, are configured to send not only PIMjoin/prune messages but also send path list messages, shown as a PIMPath List message 210. In order to not clutter the drawing, only onepath list message is labeled in FIG. 2, but all dotted arrows shown inthe network environment 200 are intended to illustrate propagation ofsuch a path list messages. Thus, as can be seen in the networkenvironment 200, each path list message as described herein ispropagated to each of the network nodes by the network nodes passing thepath list message to its peers, i.e. in a hop-by-hop manner, a processknown as “flooding” of messages in a network. In contrast, as can alsobe seen in the network environment 200 with solid arrows labeled as aPIM join/prune message 210, such messages are advertised by each nodeonly to its RPF neighbor in a given sequence of nodes according to agiven network path. FIG. 2 illustrates one example for the PIMjoin/prune message 210 being advertised for a particular exemplarynetwork path that includes a sequence of nodes {R2, R3, R4, R5, R6}, PIMjoin/prune messages (i.e. from R1 to R2, from R2 to R3, etc.). Ofcourse, when a different path is to be advertised, the PIM join/prunemessage 210 would traverse the sequence of network nodes in accordancewith that path.

FIGS. 3A-3C provide examples of, respectively, a conventional PIMjoin/prune message (e.g. a message as shown in FIG. 1), a path listmessage as proposed herein, and a PIM join/prune message as proposedherein for announcing one or more paths to one or more sources in thenetwork environment 200 shown in FIG. 2.

FIG. 3A illustrates a conventional PIM join/prune message 300 whichwould include at least one field 302 encoding an identification of amulticast group, e.g. a group Gi (where the index “i” indicates that itcould be any one of the multicast groups which may be supported in thenetwork environment 200, e.g. G1, G2, G3, etc.), that a host, e.g. hostH1, indicated the desire to join. The conventional PIM join/prunemessage 300 further includes a field 304 encoding an identification of amulticast source, e.g. a multicast source Sj (where the index “j”indicates that it could be any one of the multicast sources which may besend requested multicast traffic to the group Gi specified in the field302). In addition, the conventional PIM join/prune message 300 alsoincludes a field 306 encoding an explicit path from a downstream nodefor the host that requested multicast traffic to an upstream nodeassociated with the source identified in the field 304. The explicitpath is shown in the field 306 as “Sequence_k” indicating that theexplicit path is a sequence of two or more network nodes from thedownstream node to the upstream node (the index “k” indicates that itcould be any one of the possible network paths supported by the networkenvironment 200 for delivering requested multicast traffic from thesource Sj specified in the field 304 to the group Gi specified in thefield 302). In a sequence of a given path, one or more nodes between thedownstream and the upstream nodes are referred to herein as“intermediate” nodes.

The fields 302, 304, and 306 may be logically connected within the PIMjoin/prune message 300, forming a set 301, to indicate to network nodesreceiving and processing them, that the information encoded in thesefields is associated with one another. In general, the PIM join/prunemessage 300 may include additional sets 301, specifying groups, sources,and explicit paths lists as known in the art. In some embodiments, whentwo or more different sets refer to the same group, they may includeonly one field specifying the group for all of them (as e.g. shown inFIG. 6A, described below). The PIM join/prune message 300 may e.g. besent as the PIM join/prune message 104 shown in FIG. 1.

FIG. 3B illustrates an exemplary path list message 320, which, togetherwith a new PIM join/prune message 340 shown in FIG. 3C, may be used inthe network environment 200 as the path list message 210 and the PIMjoin/prune message 204, respectively, in accordance with variousembodiments described herein. As shown in FIG. 3B, the path list message320 includes N sets of fields, labeled as sets 1 . . . N, where N is aninteger equal to or greater than 1. Each set includes a first fieldencoding a different explicit network path from a downstream node for ahost that requested multicast traffic to an upstream node associatedwith the source (e.g. field 324 of set 1 and field 334 of set N), and asecond field (e.g. field 326 of set 1 and field 336 of set N) encoding adifferent identifier assigned to represent the network path specified inthe first field. According to various embodiments of the presentdisclosure, two network paths are considered to be different when asequence of network nodes specified by one network path includes atleast one network node not present in the sequence of network nodesspecified by another network path, or when the order of the networknodes within those sequences is different. Thus, a new identifier isassigned to each new network path. Furthermore, in some embodiments, thesame network paths specified for different sources, groups, or hosts maybe assigned the same identifiers, if updates in those paths are expectedto be applicable to all of these sources/groups/hosts. In otherembodiments, the same network paths specified for different sources,groups, or hosts may be assigned different unique identifiers, ifupdates in those paths are not expected to be applicable to all of thesesources/groups/hosts. The path list message 320 may e.g. be sent as thePIM Path List message 210 shown in FIG. 2.

In various embodiments, an identifier associated with a specifiednetwork path for forwarding multicast traffic may be any value thatallows uniquely identifying that network path within a given network.For example, in some embodiments, such an identifier may be a uniquee.g. 32-64-bit value in that network domain.

FIG. 3C illustrates an exemplary PIM join/prune message 340 which may besent as the PIM join/prune message 204 shown in FIG. 2. As shown in FIG.3C, similar to the conventional PIM join/prune message 300, the PIMjoin/prune message 340 include at least one field 342 encoding anidentification of a multicast group, e.g. a group Gi, that a host, e.g.host H1, indicated the desire to join (i.e. the field 342 of the PIMjoin/prune message 340 is similar to the field 302 of the PIM join/prunemessage 300). Also similar the conventional PIM join/prune message 300,the PIM join/prune message 340 further includes a field 344 encoding anidentification of a multicast source, e.g. a multicast source Sj (i.e.the field 344 of the PIM join/prune message 340 is similar to the field304 of the PIM join/prune message 300). In contrast to the conventionalPIM join/prune message 300, the PIM join/prune message 340 furtherincludes a field 346 encoding an identification of the identifierassociated with a network path specified for the multicast group encodedin the field 342 and for the multicast source encoded in the field 344(i.e. the field 346 of the PIM join/prune message 340 is different fromthe field 306 of the PIM join/prune message 300 in that the former onlyincludes an identifier of a network path while the latter includes thesequence of nodes, i.e. the network path itself). In contrast toconventional implementations, not having to encode the actual path listin the field 346 of the PIM join/prune message 340 advantageouslyreduces the size of the PIM join/prune message 340.

The fields 342, 344, and 346 are logically connected within the PIMjoin/prune message 340, forming a set 341, to indicate to network nodesreceiving and processing them, that the information encoded in thesefields is associated with one another. In general, the PIM join/prunemessage 340 may include additional sets 341, specifying groups, sources,and explicit paths lists as known in the art. In some embodiments, whentwo or more different sets refer to the same group, they may includeonly one field specifying the group for all of them (as e.g. shown inFIG. 6C, described below).

Besides the fact that the PIM join/prune messages 340 includeidentifiers of network paths instead of the actual network pathsthemselves, and besides the fact that the PIM join/prune messages 340may not have to be re-originated by a network node if a path update doesnot affect the configuration of the node with respect to its' immediatepeer nodes (described in greater detail below), the PIM join/prunemessages 340 may be organized, transmitted, and processed as known inthe art for the conventional PIM join/prune messages used to distributemulticast network path information in a network environment, all ofwhich being within the scope of the present disclosure.

In some embodiments, the sets 1 . . . N of a single path list message320 may include path lists which would be sent in separate PIMjoin/prune messages 340. In other words, there does not have to be aone-to-one correspondence between the sets of a given PIM join/prunemessage 340 and a given path list message 320 (and for that reason thesets of these messages are labeled in FIGS. 3B and 3C differently). Suchembodiments may be advantageous in that a downstream node may firstcollect a plurality of network paths to be announced and then announceall of them in a single path list message.

Each network node in the network environment 200, upon receiving thepath list message 210, e.g. the path list message 320, will store theassociation between the path identifier encoded in one field of a set(e.g. encoded in the field 324) and the explicit path list encoded inanother field of the same set (e.g. encoded in the corresponding field326). The network node will do so for each of the N sets included in thepath list message 210. Any manner of storing this information extractedfrom the path list messages that will allow the network node to laterobtain the explicit path list based on a given identifier, e.g. asreceived within the PIM join/prune message 210, e.g. the message 340, asdescribed herein, is within the scope of the present disclosure.

Upon receiving the PIM join/prune message 204, e.g. the PIM join/prunemessage 340, each node will obtain an identifier from one field of a set(e.g. encoded in the field 346), access the associations betweenidentifiers and explicit network paths which were assembled based oninformation of the path lit messages 210, and use the identifierindicated in a given field of a PIM join/prune message 340 to obtain theactual explicit path associated with that identifier. Thus, if the field346 encodes an identifier ID_1, then the node will determine that theassociated sequence of network nodes is Sequence_1, as can be seen fromthe path list message 320 shown in FIG. 3B.

Once the node obtained the actual path list for each of the identifiersencoded in the PIM join/prune message 204, the node can process them asknown in the art for processing the PIM join/prune messages 104, asdescribed above (e.g. create a multicast forwarding entry in its table,configure its upstream and downstream interfaces, etc.), except, again,for when there is a path update, which will now be described.

Consider a case that there is a path update to one network path forwhich the information was announced in the network environment 200, i.e.the path list for a given group and a given source becomes a different.For example, with reference to the nodes shown in FIG. 2, consider thatthe Sequence_1 was originally a sequence {R2, R3, R4, R5, R6}, but thenit changes to a sequence {R2, R3, R4, R7, R6}. As is shown in FIG. 3B,path identifier ID_1 was assigned to that sequence (field 324,corresponding to field 326, within the path list message 320). Toannounce this path update, the downstream node R1 will re-transmit thepath list message 320 but, this time, the field 326 will encode theupdated sequence of nodes: Sequence_2 (i.e. this time it will encodesequence {R2, R3, R4, R7, R6}). The field 324 encoding the pathidentifier associated with the updated sequence will remain the same,i.e. ID_1. All of the nodes receiving the re-transmitted path listmessage 320 with the updated sequence Sequence_2 will process themessage 320 as described above and update the associations betweenidentifiers and sequences accordingly.

In some embodiments of the present disclosure, in order to achievefurther advantages enabled by using the identifiers, distribution of PIMjoin/prune messages in case of a path update may be modified, comparedto conventional implementation.

As described above, according to conventional implementations, whenthere is a change in the path that was previously specified, then thePIM join/prune messages carrying the updated path are re-sent andre-processed by each of the nodes involved, starting with the downstreamnode R1. In contrast to that inefficient implementation, according toembodiments of the present disclosure, not all of these PIM join/prunemessages need to be re-sent and re-processed. Namely, each network nodein the network environment 200, in response to receiving a subsequentpath list message 210 specifying a different sequence for a given pathidentifier provided to the node before, is configured to check whetherthe node that is next to that node in the updated sequence (i.e., thenew next node) is different from the next node specified by the previoussequence (i.e. the old next node).

If the new next node is not the same as the old next node, than the nodewill send an appropriate PIM join message to the new next node specifiedby the updated sequence and configure its' upstream interface to receivemulticast traffic from the new next node. The PIM join message willinclude the group ID and source ID for the network path, which two IDshave not changed, the PIM join message will further include the pathidentifier identifying the updated path (which is the same identifier asthe one that was used for the old path). The node will also send a PIMprune message to the old next node, thereby pruning (i.e. eliminating)the link to the old next node for receiving multicast traffic from it.Pruning may be performed as known in the art, except that now the PIMprune messages will be messages like the message 340, i.e. include theidentifier instead of the actual path list being pruned.

If the new next node is the same as the old next node, then the nodedoes not need to do anything further because the path update does notaffect that node. In such a case, transmission of a PIM join/prunemessage as was done in the prior art is suppressed or prevented, becausethe link to the next node of the updated sequence is already in placeand the interfaces of the node have already been properly configured.

As the foregoing illustrates, in contrast to the conventionalimplementation as described with reference to FIG. 1, introducing anidentifier for each unique network path specified in path list messagesand then only using the identifiers in the PIM join/prune messages,instead of the network paths themselves, advantageously allows reducingthe number of messages traversing the network because PIM join/prunemessages can be made significantly smaller and the same paths don't haveto be repeated for each source, group, or host. In addition, in casethere is a path update, only network nodes for which the next node inthe updated sequence is different from the next node in the previoussequence, will send PIM join/prune messages to the next nodes, whichmessages will, again, carry path identifiers instead of the explicitpaths. This will further reduce the amount of messages traversing thenetwork as well as reduce processing burden on the nodes.

Some exemplary scenarios and exemplary messages of using the identifiersaccording to various embodiments of the present disclosure will now bedescribed.

FIGS. 4A-4C provide examples of, respectively, a conventional PIMjoin/prune message, a path list message as proposed herein, and a PIMjoin/prune message as proposed herein for the example of a network path{R2, R3, R4, R5, R6} to the source S0 being announced by the downstreamnode R1 in response to receiving an IGMP join message indicating that H1wishes to join a multicast group G1 (the example shown in FIG. 2).

FIG. 4A illustrates a conventional PIM join/prune message 400 (in thiscase, a “join” message), which is an example of the PIM join/prunemessage 300 shown in FIG. 3A. In this example, as shown in FIG. 4A, inthe conventional implementation, the field 302 would encode theidentification of group G1, the field 304 would encode theidentification of multicast source S0, and the field 306 would encodethe sequence of nodes {R2, R3, R4, R5, R6} as the explicit network pathspecified for this multicast transmission.

FIG. 4B illustrates an exemplary path list message 420, according toembodiments of the present disclosure, which is an example of the pathlist message 320 shown in FIG. 3B. In this example, as shown in FIG. 4B,the field 326 would encode the explicit {R2, R3, R4, R5, R6}, while thefield 324 would encode an identifier assigned to that path, theidentifier shown in FIG. 4B as an “ID_1”, indicating that it identifiesthe particular sequence of network nodes representing a desired networkpath encoded in the field 324.

FIG. 4C illustrates an exemplary PIM join/prune message 440 (in thiscase, a “join” message), according to embodiments of the presentdisclosure, which is an example of the PIM join/prune message 340 shownin FIG. 3C. In this example, as shown in FIG. 4C, the field 342 wouldencode the identification of group G1 and the field 344 would encode theidentification of multicast source S0, similar to the conventionalimplementation, but the field 346 would encode an identification of theidentifier associated with the specified path {R2, R3, R4, R5, R6}instead of the path itself. Thus, in this example, the field 346 wouldinclude the identifier ID_1 which was assigned to the path {R2, R3, R4,R5, R6}.

FIG. 5 is a simplified block diagram illustrating the networkenvironment 200 as shown in FIG. 2, except that now illustrating anexample of distributing network path information using path listmessages 510 and PIM join/prune messages 504 in which a single pathidentifier can be used for multiple sources, according to someembodiments of the present disclosure. The PIM join/prune messages 504are analogous to the PIM join/prune messages 204/340, and the path listmessages 510 are analogous to the path list messages 210/320, shown inFIGS. 2 and 3, described above. In the interests of brevity thesedescriptions are not repeated here. In addition to the source S0 and thehost H1 as shown in FIG. 2, FIG. 5 further illustrates a source S1, withthe network node R6 being the upstream node for both sources S0 and S1.In the example of FIG. 5, it is assumed that both sources S0 and S1belong to the same multicast group, e.g. a group G1, which the host H1indicated a desire to join, and that both sources S0 and S1 should sendmulticast traffic via the same path {R2, R3, R4, R5, R6}.

FIGS. 6A-6C provide examples of, respectively, a conventional PIMjoin/prune message, a path list message as proposed herein, and a PIMjoin/prune message as proposed herein for the example of FIG. 5.

FIG. 6A illustrates a conventional PIM join/prune message 600 (in thiscase, a “join” message), which is an example of the PIM join/prunemessage 300 shown in FIG. 3A. In this example, as shown in FIG. 6A, inthe conventional implementation, the field 302 would encode theidentification of group G1, the field 304 would encode theidentification of multicast source S0, and the field 306 would encodethe sequence of nodes {R2, R3, R4, R5, R6} as the explicit network pathspecified for this multicast transmission. In addition, as is the casewhen there are multiple multicast sources in the same group, theconventional PIM join/prune message 600 would also include a field 604,similar to the field 304, but this time encoding an identification ofthe second multicast source, S1, and would further include a field 606,similar to the field 306, including the same path to the source S1, {R2,R3, R4, R5, R6}, as is the example of FIG. 5. Encoding the same explicitlist for each of the multiple sources, as shown in FIG. 6A, can quicklymake the PIM join/prune message 600 very large.

FIG. 6B illustrates an exemplary path list message 620, according toembodiments of the present disclosure, which is an example of the pathlist message 320 shown in FIG. 3B, and which could be used as the pathlist message 510 shown in FIG. 5. In this example, as shown in FIG. 6B,the field 326 would encode the explicit {R2, R3, R4, R5, R6}, while thefield 324 would encode an identifier assigned to that path, theidentifier shown in FIG. 6B as an “ID_1”, indicating that it identifiesthe particular sequence of network nodes representing a desired networkpath encoded in the field 324. A single identifier ID_1 may be used toidentify the same sequence {R2, R3, R4, R5, R6} to two differentsources.

FIG. 6C illustrates an exemplary PIM join/prune message 640 (in thiscase, a “join” message), according to embodiments of the presentdisclosure, which is an example of the PIM join/prune message 340 shownin FIG. 3C, and which could be used as the PIM join/prune message 504shown in FIG. 5. In this example, as shown in FIG. 6C, the field 342would encode the identification of group G1 and the field 344 wouldencode the identification of multicast source S0, similar to theconventional implementation, but the field 346 would encode anidentification of the identifier associated with the specified path {R2,R3, R4, R5, R6} instead of the path itself. Thus, in this example, thefield 346 would include the identifier ID_1 which was assigned to thepath {R2, R3, R4, R5, R6}.

In addition, the same as with the conventional implementation of FIG.6A, the PIM join/prune message 640 would also include a field 644,similar to the fields 344 and 604, but this time encoding anidentification of the second multicast source, S1, and would furtherinclude a field 646, similar to the fields 346 and 606, including thesame the identifier associated with the specified path {R2, R3, R4, R5,R6} to the source S1 as that included in the field 346, instead of thepath itself. Encoding the same identifier for each of the multiplesources, instead of encoding the same complete path for each source, asshown in FIG. 6C, reduces the size of the PIM join/prune message 640compared to that of the PIM join/prune message 600.

FIG. 7 is a simplified block diagram illustrating the networkenvironment 200 as shown in FIG. 2, except that now illustrating anexample of distributing network path information using path listmessages 710 and PIM join/prune messages 704 and 712 in which multiplepaths and their path identifiers can be announced in a single path listmessage, according to some embodiments of the present disclosure. Eachof the PIM join/prune messages 704 and 712 are analogous to the PIMjoin/prune messages 204/340, and the path list messages 710 areanalogous to the path list messages 210/320, shown in FIGS. 2-3,described above. In the interests of brevity these descriptions are notrepeated here. In addition to the source S0 and the host H1 as shown inFIG. 2, FIG. 7 further illustrates a source S1, with the network node R6being the upstream node for both sources S0 and S1, similar to theexample of FIG. 5. Unlike the example of FIG. 5, in the example of FIG.7, it is assumed that each of the sources S0 and S1 should sendmulticast traffic via its' respective path. The path for the source S0is a path {R2, R3, R4, R5, R6}, shown in FIG. 7 by illustrating that thePIM join/prune message 704 traverses that path, and the path for thesource S1 is a path {R22, R33, R44, R55, R6}, shown in FIG. 7 byillustrating that the PIM join/prune message 712 traverses that path.The sources S0 and S1 may belong to the same or different multicastgroups.

FIGS. 8A-8C provide examples of, respectively, a conventional PIMjoin/prune message, a path list message as proposed herein, and a PIMjoin/prune message as proposed herein for the example of FIG. 7.

FIG. 8A illustrates conventional PIM join/prune messages 800 and 810 (inthis case, “join” messages), each of which is an example of the PIMjoin/prune message 300 shown in FIG. 3A. In this example, the downstreamnode R1 will announce routes to S0 and S1 in different PIM join/prunemessages because the RPF neighbor for the paths for S0 and S1 aredifferent for R1 (its R2 for the path for S0 and its R22 for the pathfor S1, for the example of FIG. 7). In this example, as shown in FIG.8A, in the conventional implementation, the field 302 of the PIMjoin/prune message 800 would encode the identification of group G1 (thegroup for which the multicast source S0 of FIG. 7 is assumed to providemulticast traffic for), the field 304 would encode the identification ofmulticast source S0, and the field 306 would encode the sequence ofnodes {R2, R3, R4, R5, R6} as the explicit network path specified forthis multicast transmission for source S0. Similarly, in theconventional implementation, the field 302 of the PIM join/prune message810 would encode the identification of group G2 (the group for which themulticast source S1 of FIG. 7 is assumed to provide multicast trafficfor), the field 304 would encode the identification of multicast sourceS1, and the field 306 would encode the sequence of nodes {R22, R33, R44,R55, R6} as the explicit network path specified for this multicasttransmission for source S1.

FIG. 8B illustrates an exemplary path list message 820, according toembodiments of the present disclosure, which is an example of the pathlist message 320 shown in FIG. 3B, and which could be used as the pathlist message 710 shown in FIG. 7. In this example, as shown in FIG. 8B,the field 326 of the path list message 820 would encode the explicitpath {R2, R3, R4, R5, R6} to S0, while the field 324 would encode anidentifier assigned to that path, the identifier shown in FIG. 8B as an“ID_1”, indicating that it identifies the particular sequence of networknodes representing a desired network path encoded in the field 324. Inaddition, the path list message 820 further includes the field 336,encoding the explicit path {R22, R33, R44, R55, R6} to S1, and the field334, encoding an identifier assigned to the path encoded in the field334, the identifier shown in FIG. 8B as an “ID_2”.

FIG. 8C illustrates an exemplary PIM join/prune message 840 (in thiscase, a “join” message), according to embodiments of the presentdisclosure, which is an example of the PIM join/prune message 340 shownin FIG. 3C, and which could be used as the PIM join/prune message 704shown in FIG. 7. In this example, as shown in FIG. 8C, the field 342 ofthe PIM join/prune message 840 would encode the identification of groupG1 and the field 344 would encode the identification of multicast sourceS0, similar to the conventional implementation shown in FIG. 8A with themessage 800, but the field 346 would encode an identification of theidentifier associated with the specified path {R2, R3, R4, R5, R6}instead of the path itself. Thus, in this example, the field 346 of thePIM join/prune message 840 would include the identifier ID_1 which wasassigned to the path {R2, R3, R4, R5, R6}. Similarly, the field 342 ofthe PIM join/prune message 850 would encode the identification of groupG2 and the field 344 would encode the identification of multicast sourceS1, similar to the conventional implementation shown in FIG. 8A with themessage 810, but the field 346 would encode an identification of theidentifier associated with the specified path {R22, R33, R44, R55, R6}instead of the path itself. Thus, in this example, the field 346 of thePIM join/prune message 850 would include the identifier ID_2 which wasassigned to the path {R22, R33, R44, R55, R6}.

FIGS. 8B and 8C illustrate that, even though network paths to S0 and S1are announced via different PIM join/prune messages 840 and 850, thesenetwork paths may be announced in a single path list message 820.

An example of FIGS. 7 and 8A-8C could easily be extended to Live-Liveembodiments where different paths, e.g. paths {R2, R3, R4, R5, R6} and{R22, R33, R44, R55, R6} as shown in FIG. 7 are specified for reaching asingle source S0. In such embodiments, the messages shown in FIGS. 8A-8Cwould need to replace source S1 with source S0 and group G2 with groupG1, but otherwise explanations provided above would still apply.

FIG. 9 is a simplified block diagram illustrating the networkenvironment 200 as shown in FIG. 2, except that now illustrating anexample of an update in the network path from a path {R2, R3, R4, R5,R6} to a path {R2, R3, R4, R7, R6}, according to some embodiments of thepresent disclosure. FIG. 9 illustrates the path update example describedabove and assumes that, first path information for the path {R2, R3, R4,R5, R6} was distributed, which can be done as described for the exampleof FIG. 2 with the messages shown in FIGS. 4A-4B. FIG. 9 illustrates acontinuation of this example where the path change occurs, e.g. becausethe node R5 became dysfunctional. As was described above, whenSequence_1 that was originally a sequence {R2, R3, R4, R5, R6} isupdated, e.g. to a Sequence_2 that includes nodes {R2, R3, R4, R7, R6},the downstream node R1 will re-transmit the path list message, as shownin FIG. 9 with a path list message 910. The path list message 910 isanalogous to the path list message announcing the Sequence_1 earlier,i.e. the message as shown in FIG. 4B, but, this time, it will carry theupdated sequence of nodes (i.e. this time it will encode sequence {R2,R3, R4, R7, R6}). The path list message 910 will still be flooded to allnetwork nodes in the network environment 200, as shown in FIG. 9 withthe dotted arrows. On the other hand, the new PIM join/prune messages914 that are sent in view of the update will only be transmitted bythose network nodes for which the RPF neighbor is changed due to theupdate. For the example of an update from the path {R2, R3, R4, R5, R6}to the path {R2, R3, R4, R7, R6}, these are nodes R4, R5, and R7. FIG. 9illustrates that by showing PIM prune messages 914 (indicated withdash-dotted arrows) going from R4 to R5, and from R5 to R6, and byshowing PIM join messages 916 (indicated with solid arrows) going fromR4 to R7, and from R7 to R6.

FIGS. 10A-10C provide examples of, respectively, conventional old andnew PIM join/prune message, old and new path list messages as proposedherein, and old and new PIM join/prune messages as proposed herein forthe example of FIG. 9.

FIG. 10A illustrates conventional PIM join/prune messages 1000 and 1010,each of which is an example of the PIM join/prune message 300 shown inFIG. 3A. The conventional PIM join/prune message 1000 is the oldmessage, announcing the old path {R2, R3, R4, R5, R6}, and is the sameas the conventional PIM join/prune message 400 shown in FIG. 4A anddescribed above. Similarly, the old path message 1020 shown in FIG. 10Band the old PIM join/prune message 1040 shown in FIG. 10C are the sameas respective messages shown in FIGS. 4B and 4C. In the interests ofbrevity, descriptions of these old messages is not repeated here.

The new PIM join/prune message 1010 which would be sent in conventionalimplementations would encode the updated path list in its field 306, asshown in FIG. 10A. The fields 302 and 304 of this message would remainthe same as for the old PIM join/prune message 1000.

The new path list message 1030 which would be sent according to thepresent disclosure would encode the updated path list in its field 326,i.e. path list {R2, R3, R4, R7, R6}, as shown in FIG. 10B. The field 324of this message would remain the same as for the old path list message1020.

The new PIM join/prune message 1050 which would be sent according to thepresent disclosure would be the same as the old PIM join/prune message1040, as shown in FIG. 10C, because the identifier does not change andthe actual change in the path was communicated to the nodes via the pathlist message 1020. Such a new PIM join/message 1050 would only be sentby nodes which are affected by the change, as described above.

FIG. 11 is a flow diagram of a method 1100 for distributing network pathinformation using path list messages and PIM join/prune messages,according to some embodiments of the present disclosure. Althoughdescriptions of the method 1100 may refer to elements shown in some ofthe previous FIGURES, any system, configured to perform the steps of themethod 1100, in any order, is within the scope of the presentdisclosure.

The method 1100 may begin a step 1102 where a downstream node, e.g. nodeR1, transmitting a first message that announces a sequence of nodes in aspecified network path for a given group and source, as well as a pathidentifier assigned to the path. The first message may e.g. be the pathlist message 210, 320, 420, 620, 820, or 1020. In some embodiments, instep 1102, the first message may be flooded to all of the network nodesin the network environment 200 (where “all of the network nodes” areunderstood to include the nodes configured to operate according with theembodiments of the present disclosure).

In step 1104, the downstream node, e.g. node R1, transmits a secondmessage advertising a multicast source and a path identifier assigned tothe path that is the network path for the advertised source. The secondmessage may e.g. be the PIM join/prune message 204, 340, 440, 640, 840,or 1040. The second message is transmitted to the RPF neighbor of thedownstream node according to the network path identified by the secondmessage.

In step 1106, the downstream node, e.g. node R1, transmits a thirdmessage announcing an updated sequence of nodes in an updated networkpath for a given group and source, with the path identifier that wasassigned to the old path. The third message may e.g. be the path listmessage 210, 910, or 1030. In some embodiments, in step 1106, the thirdmessage may be flooded to all of the network nodes in the networkenvironment 200.

In step 1108, only those nodes which are not the upstream nodes for theannounced path and for which the RPF neighbor changed when the pathchanged from the old path to the updated path announced in 1106,transmit a fourth message advertising the multicast source as in 1102and the path identifier assigned to the path in 1102, the pathidentifier now representing the updated network path for the advertisedsource. The fourth message may e.g. be the PIM join/prune message 204,914/916, or 1050. The fourth message is transmitted to the RPF neighborof the nodes affected by the update.

Exemplary Devices

FIG. 12 illustrates an example network device 1200 suitable forimplementing various embodiments of the present disclosure, e.g.embodiments related to distributing network path information. In variousembodiments, the network device 1200 could be any one of network nodesdescribed herein, e.g. the network device 1200 may be used to implementthe functionality of any one of the nodes within the network environment200, such as e.g. any one of the nodes R1-R7, R22, R33, R44, and R55,shown in FIG. 2. In some embodiments, the network device 1200 could becommunicatively connected to any one of network elements describedherein in order to configure any one of these elements to carry outtheir functionality in distributing network path information asdescribed herein.

As shown in FIG. 12, the network device 1200 includes a master centralprocessing unit (CPU) 1210, interfaces 1220, and a bus 1230 (e.g., a PCIbus). When acting under the control of appropriate software or firmware,the CPU 1210 may be responsible for executing processing of path listand PIM join/prune messages, packet management, error detection, and/orrouting or forwarding functions. The CPU 1210 can accomplish all thesefunctions under the control of software including an operating systemand any appropriate applications software. CPU 1210 may include one ormore processors 1214 such as e.g. a processor from the Motorola familyof microprocessors or the MIPS family of microprocessors. In analternative embodiment, processor 1214 is specially designed hardwarefor controlling the operations of network device 1200 in accordance withembodiments described herein. In a specific embodiment, a memory 1212(such as non-volatile RAM and/or ROM) also forms part of CPU 1210.However, there are many different ways in which memory could be coupledto the system.

The interfaces 1220 are typically provided as interface cards (sometimesreferred to as “line cards”). Generally, they control the sending andreceiving of data packets over the network and sometimes support otherperipherals used with the network device 1200. Among the interfaces thatmay be provided are Ethernet interfaces, frame relay interfaces, cableinterfaces, DSL interfaces, token ring interfaces, and the like. Inaddition, various very high-speed interfaces may be provided such asfast token ring interfaces, wireless interfaces, Ethernet interfaces,Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POSinterfaces, FDDI interfaces and the like. Generally, these interfacesmay include ports appropriate for communication with the appropriatemedia. In some cases, they may also include an independent processorand, in some instances, volatile RAM. The independent processors maycontrol such communications intensive tasks as packet switching, mediacontrol and management. By providing separate processors for thecommunications intensive tasks, these interfaces allow the mastermicroprocessor 1210 to efficiently perform routing computations, networkdiagnostics, security functions, etc.

Although the system shown in FIG. 12 is one specific network device ofthe present disclosure, it is by no means the only network devicearchitecture on which the present disclosure can be implemented. Forexample, an architecture having a single processor that handlescommunications as well as routing computations, etc. is often used.Further, other types of interfaces and media could also be used with therouter.

Regardless of the network device's configuration, it may employ one ormore memories or memory modules (including memory 1212) configured tostore program instructions for the general-purpose network operationsand mechanisms for roaming, route optimization and routing functionsdescribed herein. The program instructions may control the operation ofan operating system and/or one or more applications, for example. Thememory or memories may also be configured to store tables such asmobility binding, registration, and association tables, etc.

FIGS. 13 and 14 illustrate example systems, according to someembodiments of the present disclosure. The more appropriate embodimentwill be apparent to those of ordinary skill in the art when practicingthe present technology. Persons of ordinary skill in the art will alsoreadily appreciate that other system embodiments are possible.

Systems such as the ones shown in FIGS. 13 and 14 are also suitable forimplementing various embodiments of the present disclosure, e.g.embodiments related to distributing network path information describedherein. In various embodiments, such systems could be any one of orcould be communicatively connected to in order to configure any one ofthe network nodes described herein to enable functionality of thesenodes as described above, e.g. any of the network nodes of the networkenvironment 200 shown in FIG. 2.

FIG. 13 illustrates a conventional system bus computing systemarchitecture 1300 wherein the components of the system are in electricalcommunication with each other. Exemplary system 1300 includes aprocessing unit (CPU or processor) 1302, communicatively connected to asystem bus 1306. The system bus 1306 couples various system componentsto the processor 1302, the system components including e.g. a systemmemory 1308, a read only memory (ROM) 1310, and a random access memory(RAM) 1312. The system 1300 can include a cache 1304 of high-speedmemory connected directly with, in close proximity to, or integrated aspart of the processor 1302. The system 1300 can copy data from thememory 1308 and/or the storage device 1314 to the cache 1304 for quickaccess by the processor 1302. In this way, the cache 1304 can provide aperformance boost that avoids processor 1302 delays while waiting fordata. These and other modules can control or be configured to controlthe processor 1302 to perform various actions. Other system memory 1308may be available for use as well. The memory 1308 can include multipledifferent types of memory with different performance characteristics.The processor 1302 can include any general purpose processor and ahardware module or software module, such as module 1 1316, module 21318, and module 3 1320 stored in the storage device 1314, configured tocontrol the processor 1302 as well as a special-purpose processor wheresoftware instructions are incorporated into the actual processor design.The processor 1302 may essentially be a completely self-containedcomputing system, containing multiple cores or processors, a bus, memorycontroller, cache, etc. A multi-core processor may be symmetric orasymmetric.

To enable user interaction with the computing device 1300, an inputdevice 1322 can represent any number of input mechanisms, such as amicrophone for speech, a touch-sensitive screen for gesture or graphicalinput, keyboard, mouse, motion input, speech and so forth. An outputdevice 1324 can also be one or more of a number of output mechanismsknown to those of skill in the art. In some instances, multimodalsystems can enable a user to provide multiple types of input tocommunicate with the computing device 1300. The communications interface1326 can generally govern and manage the user input and system output.There is no restriction on operating on any particular hardwarearrangement and therefore the basic features here may easily besubstituted for improved hardware or firmware arrangements as they aredeveloped.

Storage device 1314 is a non-volatile memory and can be a hard disk orother types of computer readable media which can store data that areaccessible by a computer, such as magnetic cassettes, flash memorycards, solid state memory devices, digital versatile disks, cartridges,random access memories (RAMs) 1312, read only memory (ROM) 1310, andhybrids thereof.

The storage device 1314 can include software modules 1316, 1318, 1320for controlling the processor 1302. Other hardware or software modulesare contemplated. The storage device 1314 can be connected to the systembus 1306. In one aspect, a hardware module that performs a particularfunction can include the software component stored in a non-transitorycomputer-readable medium in connection with the necessary hardwarecomponents, such as the processor 1302, bus 1306, display 1324, and soforth, to carry out the function.

FIG. 14 illustrates an example computer system 1400 having a chipsetarchitecture that can be used in executing the described method andgenerating and displaying a graphical user interface (GUI). Computersystem 1400 is an example of computer hardware, software, and firmwarethat can be used to implement the disclosed technology. System 1400 caninclude a processor 1402, representative of any number of physicallyand/or logically distinct resources capable of executing software,firmware, and hardware configured to perform identified computations.Processor 1402 can communicate with a chipset 1404 that can controlinput to and output from processor 1402. In this example, chipset 1404outputs information to output 1406, such as a display, and can read andwrite information to storage device 1408, which can include magneticmedia, and solid state media, for example. Chipset 1404 can also readdata from and write data to RAM 1410. A bridge 1412 for interfacing witha variety of user interface components 1414 can be provided forinterfacing with chipset 1404. Such user interface components 1414 caninclude a keyboard, a microphone, touch detection and processingcircuitry, a pointing device, such as a mouse, and so on. In general,inputs to system 1400 can come from any of a variety of sources, machinegenerated and/or human generated.

Chipset 1404 can also interface with one or more communicationinterfaces 1416 that can have different physical interfaces. Suchcommunication interfaces can include interfaces for wired and wirelesslocal area networks, for broadband wireless networks, as well aspersonal area networks. Some applications of the methods for generating,displaying, and using the GUI disclosed herein can include receivingordered datasets over the physical interface or be generated by themachine itself by processor 1402 analyzing data stored in storage 1408or 1410. Further, the machine can receive inputs from a user via userinterface components 1414 and execute appropriate functions, such asbrowsing functions by interpreting these inputs using processor 1402.

It can be appreciated that example systems 1300 and 1400 can have morethan one processor 1302, 1402, or be part of a group or cluster ofcomputing devices networked together to provide greater processingcapability.

SELECTED EXAMPLES

Example 1 provides a method that includes generating a first message forannouncing a network path indicating a route for a multicast trafficfrom a multicast source to a host, the network path specifying asequence of one or more intermediate network nodes between a downstreamnode communicatively connected to the host and an upstream nodecommunicatively connected to the multicast source; generating a secondmessage for announcing that the multicast source is to be reached viasaid network path; and transmitting the first message and the secondmessage. In some Examples, the first message is flooded to all ofnetwork nodes in the network node, while the second message istransmitted to a first node of said sequence, i.e. to the RPF neighborof the downstream node according to said sequence. The first messageincludes a field encoding said sequence from the downstream node to theupstream node, the second message includes a field encoding anidentification of the multicast source, and both the first message andthe second message include a field encoding a value of an identifier foridentifying said sequence from the downstream node to the upstream node.

Example 2 provides the method according to Example 1, where theidentifier included in the second message is provided instead ofincluding said sequence in the second message. In this manner, thenetwork path which should have been advertised along with theidentification of the multicast source is replaced by the identifierwhich is shorter in length.

Example 3 provides the method according to Examples 1 or 2, where thesecond message is a protocol-independent-multicast (PIM) join/prunemessage.

Example 4 provides the method according to any one of Examples 1-3,further including, when an updated network path replaces the networkpath, generating a third message for announcing the updated network pathindicating an updated route for the multicast traffic from the multicastsource to the host, the updated network path specifying an updatedsequence of one or more intermediate network nodes between thedownstream node and the upstream node, where the updated sequence isdifferent from the original sequence in at least one network node, wherethe third message includes a field encoding said updated sequence fromthe downstream node to the upstream node and a field encoding a value ofthe identifier for identifying said sequence (i.e. an updated sequenceof network nodes is associated with the same identifier that was usedfor the original sequence of nodes that was transmitted in the firstmessage, as specified by the third message by including the updatedsequence in association with original identifier that was included inthe first message); and transmitting the third message e.g. by floodingthe third message to the network.

Example 5 provides the method according to Example 4, where, when afirst node of said updated sequence is different from a first node ofsaid original sequence, the method further includes generating andtransmitting a fourth message for announcing that the multicast sourceis to be reached via said updated network path, the fourth messageincluding a field encoding the identification of the multicast sourceand a field encoding a value of the identifier for identifying saidsequence.

Example 6 provides the method according to Example 4, where, when afirst node of said updated sequence is the same as a first node of saidoriginal sequence, the method further includes suppressing generatingand transmitting a fourth message for announcing that the multicastsource is to be reached via said updated network path, the fourthmessage including a field encoding the identification of the multicastsource and a field encoding a value of the identifier for identifyingsaid sequence. In other words, the downstream node re-originates a PIMjoin/prune message by generating and transmitting the fourth message asdescribed herein only when the first node in the sequence of nodes (i.e.the RPF neighbor node for the path from the downstream node to theupstream node) changes.

Example 7 provides the method according to Examples 5 or 6, where thefourth message is a protocol-independent-multicast (PIM) join/prunemessage.

Example 8 provides the method according to any one of the precedingExamples, where said multicast source is a first multicast source, saidnetwork path is a first network path, said sequence is a first sequence,and said identifier is a first identifier, the first message furtherincludes a field encoding a second sequence of one or more intermediatenetwork nodes between the downstream node communicatively connected tothe host and an upstream node communicatively connected to a secondmulticast source and a second identifier identifying the secondsequence, and the method further includes generating and transmitting anadditional message for announcing that the second multicast source is tobe reached via said second network path, the additional messageincluding a field encoding an identification of the second multicastsource and the second identifier identifying the second sequence.

Example 9 provides a method that includes receiving, at an intermediatenode, a first message including a field encoding a network pathindicative of a route for a multicast traffic from a multicast source toa host, the network path including a sequence of one or moreintermediate network nodes between a downstream node communicativelyconnected to the host and an upstream node communicatively connected tothe multicast source, and an identifier identifying said sequence fromthe downstream node to the upstream node; receiving, at the intermediatenode, a second message announcing that the multicast source is to bereached via said network path, the second message including a fieldencoding an identification of the multicast source, and said identifieridentifying said sequence from the downstream node to the upstream node;and transmitting, by the intermediate node, to its RPF neighbor, a thirdmessage including a field encoding said identification of the multicastsource and said identifier.

Example 10 provides the method according to Example 9, where each of thesecond message and the third message is a protocol-independent-multicast(PIM) join/prune message.

Example 11 provides the method according to Examples 9 or 10, furtherincluding the intermediate node transmitting a fourth message includinga field encoding the network path specified in the first message and theidentifier specified in the first message. Thus, the intermediate nodere-originates the path list message. All intermediate nodes doing thesame allows path list messages to flood the network (i.e. be propagatedto all network nodes of the network).

Example 12 provides the method according to Examples 10 or 11, furtherincluding receiving, at the intermediate node, a fourth messageincluding a field encoding an updated network path indicative of anupdated route for the multicast traffic from the multicast source to thehost, the updated network path including an updated sequence of one ormore intermediate network nodes between the downstream node and theupstream node, and a field encoding the value of the identifier foridentifying said sequence (i.e. an updated sequence of network nodes isassociated with the same identifier that was used for the originalsequence of nodes that was transmitted in the first message, asspecified by the fourth message by including the updated sequence inassociation with original identifier that was included in the firstmessage); and, when a first node following the intermediate node in saidupdated sequence is different from the first node following theintermediate node in said original sequence, then transmitting, by theintermediate node, a fifth message including a field encoding saididentification of the multicast source and said identifier to the firstnode following the intermediate node in said updated sequence.

Example 13 provides the method according to Example 12, furtherincluding preventing transmission of the fifth message when the firstnode following the intermediate node in said updated sequence is notdifferent from (i.e. is the same as) the first node following theintermediate node in said original sequence.

Example 14 provides a method that includes transmitting a first message,the first message including a sequence of one or more network nodesrepresenting a network path for multicast traffic between an egress nodecommunicatively connected to a receiver device and an ingress nodecommunicatively connected to a multicast source device, and anidentifier associated with the sequence, and transmitting a secondmessage, the second message including an identification of the multicastsource and the identifier associated with the sequence.

Example 15 provides the method according to Example 14, furtherincluding, when an updated network path replaces the network path,transmitting a third message, the third message including an updatedsequence of one or more network nodes representing an updated networkpath replacing the network path, and the identifier associated with thesequence of the network path being replaced (i.e. an updated sequence ofnetwork nodes is associated with the same identifier that was used forthe original sequence of nodes that was transmitted in the firstmessage, as specified by the third message by including the updatedsequence in association with original identifier that was included inthe first message).

Example 16 provides the method according to Examples 14 or 15, furtherincluding, when a first node of said updated sequence is different froma first node of said original sequence, transmitting a fourth message tothe first node of said updated sequence, the fourth message including afield encoding the identification of the multicast source and a fieldencoding a value of the identifier associated with the sequence.

Example 17 provides the method according to Example 16, where the fourthmessage is a protocol-independent-multicast (PIM) join/prune message.

Example 18 provides the method according to any one of Examples 14-17,where the second message is a protocol-independent-multicast (PIM)join/prune message.

Example 19 provides the method according to any one of Examples 14-18,where the first message is transmitted to a plurality of nodes in anetwork.

Example 20 provides the method according to any one of Examples 14-16,where the second message is transmitted to a first node of the sequence.

Further Examples include a system for distributing network pathinformation for multicast traffic, the system including at least onememory element configured to store computer executable instructions andat least one processor coupled to the at least one memory element andconfigured, when executing the instructions, to carry out methodsaccording to any one of the preceding Examples.

Further Examples include one or more non-transitory computer readablestorage media encoded with software comprising computer executableinstructions and, when the software is executed, operable to carry outmethods according to any one of the preceding Examples.

Further Examples include data structures to be used in methods accordingto any one of the preceding Examples.

VARIATIONS AND IMPLEMENTATIONS

It should be noted that much of the infrastructure discussed herein canbe provisioned as a part of any type of a network node.

In one implementation, network nodes described herein can includesoftware to achieve (or to foster) the network path distributionactivities discussed herein. This could include the implementation ofinstances of any of the components, engines, logic, etc. shown in theFIGURES. Additionally, each of these devices can have an internalstructure (e.g., a processor, a memory element, etc.) to facilitate someof the operations described herein. In other embodiments, thesemanagement activities may be executed externally to these devices, orincluded in some other network element to achieve the intendedfunctionality. Alternatively, these network devices may include software(or reciprocating software) that can coordinate with other networkelements in order to achieve the management activities described herein.In still other embodiments, one or several devices may include anysuitable algorithms, hardware, software, components, modules,interfaces, or objects that facilitate the operations thereof.

Note that with the example provided above, as well as numerous otherexamples provided herein, interaction may be described in terms of two,three, or four network elements. However, this has been done forpurposes of clarity and example only. In certain cases, it may be easierto describe one or more of the functionalities of a given set of flowsby only referencing a limited number of network elements. It should beappreciated that topologies illustrated in and described with referenceto the accompanying FIGURES (and their teachings) are readily scalableand can accommodate a large number of components, as well as morecomplicated/sophisticated arrangements and configurations. Accordingly,the examples provided should not limit the scope or inhibit the broadteachings of the illustrated topologies as potentially applied to amyriad of other architectures.

It is also important to note that the steps in the preceding flowdiagrams illustrate only some of the possible signaling scenarios andpatterns that may be executed by, or within, communication systems shownin the FIGURES. Some of these steps may be deleted or removed whereappropriate, or these steps may be modified or changed considerablywithout departing from the scope of the present disclosure. In addition,a number of these operations have been described as being executedconcurrently with, or in parallel to, one or more additional operations.However, the timing of these operations may be altered considerably. Thepreceding operational flows have been offered for purposes of exampleand discussion. Substantial flexibility is provided by communicationsystems shown in the FIGURES in that any suitable arrangements,chronologies, configurations, and timing mechanisms may be providedwithout departing from the teachings of the present disclosure.

Although the present disclosure has been described in detail withreference to particular arrangements and configurations, these exampleconfigurations and arrangements may be changed significantly withoutdeparting from the scope of the present disclosure. For example,although the present disclosure has been described with reference toparticular communication exchanges, embodiments described herein may beapplicable to other architectures.

Numerous other changes, substitutions, variations, alterations, andmodifications may be ascertained to one skilled in the art and it isintended that the present disclosure encompass all such changes,substitutions, variations, alterations, and modifications as fallingwithin the scope of the appended claims. In order to assist the UnitedStates Patent and Trademark Office (USPTO) and, additionally, anyreaders of any patent issued on this application in interpreting theclaims appended hereto, Applicant wishes to note that the Applicant: (a)does not intend any of the appended claims to invoke paragraph six (6)of 35 U.S.C. section 112 as it exists on the date of the filing hereofunless the words “means for” or “step for” are specifically used in theparticular claims; and (b) does not intend, by any statement in thespecification, to limit this disclosure in any way that is not otherwisereflected in the appended claims.

What is claimed is:
 1. A method comprising: transmitting a firstmessage, the first message specifying a network path indicating a routefor multicast traffic to be passed from a multicast source to a host,wherein the first message specifies the network path by listing asequence of one or more network nodes between a downstream nodeconnected to the host and an upstream node connected to the multicastsource; and transmitting a second message subscribing the host to themulticast traffic from the multicast source via said network path,wherein the second message includes an identification of the multicastsource and an identifier for identifying the network path withoutlisting the sequence of the one or more network nodes; receiving apacket of the multicast traffic from the multicast source; forwardingthe packet of the multicast traffic to the host along the sequence ofone or more network nodes listed in the first message that areidentified by the identifier in the second message; responsive to adetermination that an updated network path replaces the network path,transmitting a third message for announcing the updated network pathindicating an updated route for the multicast traffic from the multicastsource to the host, the updated network path specifying an updatedsequence of one or more network nodes between the downstream node andthe upstream node, wherein the third message includes said updatedsequence and the identifier for identifying the network path; andresponsive to a determination that a first node of said updated sequenceis the same as a first node of said sequence, suppressing transmitting afourth message for announcing that the multicast source is to be reachedvia said updated network path.
 2. The method according to claim 1,wherein the second message is a protocol-independent-multicast (PIM)join/prune message.
 3. The method according to claim 1, wherein, whenthe first node of said updated sequence is different from the first nodeof said sequence, the method further comprises generating andtransmitting the fourth message for announcing that the multicast sourceis to be reached via said updated network path, the fourth messageincluding the identification of the multicast source and the identifierfor identifying the network path.
 4. The method according to claim 3,wherein the fourth message is a protocol-independent-multicast (PIM)join/prune message.
 5. The method according to claim 1, wherein: saidmulticast source is a first multicast source, said network path is afirst network path, said sequence is a first sequence, and saididentifier is a first identifier, the first message further specifies asecond network path by listing a second sequence of one or more networknodes between the downstream node and a second upstream node and asecond identifier identifying the second sequence, and the methodfurther includes generating and transmitting an additional message forannouncing that a second multicast source is to be reached via saidsecond network path, the additional message including an identificationof the second multicast source and the second identifier identifying thesecond sequence.
 6. The method according to claim 1, wherein the firstmessage is transmitted to a plurality of nodes in a network.
 7. A methodcomprising: receiving, at an intermediate network node between adownstream node connected to a host and an upstream node connected to amulticast source, a first message specifying a network path indicativeof a route for multicast traffic to be passed from the multicast sourceto the host, the network path comprising a sequence of one or morenetwork nodes between a downstream node and an upstream node, whereinthe first message includes an identifier identifying said sequence;receiving, at the intermediate network node, a second message announcingthat the multicast source is to be reached via said network path, thesecond message comprising an identification of the multicast source, andsaid identifier identifying said sequence; transmitting, by theintermediate network node, a third message comprising saididentification of the multicast source and said identifier; receiving apacket of the multicast traffic at the intermediate network node;forwarding the packet of the multicast traffic from the intermediatenetwork node to a first node following the intermediate network node insaid sequence; receiving, at the intermediate network node, a fourthmessage specifying an updated network path indicative of an updatedroute for the multicast traffic from the multicast source to the host,the updated network path comprising an updated sequence of one or morenetwork nodes between the downstream node and the upstream node, andsaid identifier; and responsive to a determination that a first nodefollowing the intermediate network node in said updated sequence is thesame as the first node following the intermediate network node in saidsequence, preventing transmission of a fifth message comprising saididentification of the multicast source and said identifier.
 8. Themethod according to claim 7, wherein each of the second message and thethird message is a protocol-independent-multicast (PIM) join/prunemessage.
 9. The method according to claim 7, further comprising theintermediate network node forwarding the first message specifying thenetwork path and the identifier identifying said sequence of one or morenetwork nodes.
 10. The method according to claim 7, further comprising:when the first node following the intermediate network node in saidupdated sequence is different from the first node following theintermediate network node in said sequence, then transmitting, by theintermediate network node, the fifth message comprising saididentification of the multicast source and said identifier to the firstnode following the intermediate network node in said updated sequence.11. The method according to claim 10, wherein the fifth message is aprotocol-independent-multicast (PIM) join/prune message.
 12. A systemfor distributing network path information for multicast traffic, thesystem comprising: at least one memory element configured to storecomputer executable instructions, and at least one processor coupled tothe at least one memory element and configured, when executing theinstructions, to: transmit a first message, the first message specifyinga sequence of one or more network nodes representing a network path formulticast traffic between an egress node communicatively connected to areceiver device and an ingress node communicatively connected to amulticast source device, and an identifier associated with the sequence,transmit a second message subscribing to the multicast traffic, thesecond message comprising an identification of the multicast sourcedevice and the identifier associated with the sequence without listingthe sequence; receive a packet of the multicast traffic; forward thepacket of the multicast traffic to the receiver device along thesequence of one or more network nodes specified in the first messagethat are associated with the identifier in the second message;responsive to a determination that an updated network path replaces thenetwork path, transmitting a third message comprising an updatedsequence of one or more network nodes representing the updated networkpath replacing the network path, wherein the third message includes saidupdated sequence and the identifier associated with the network pathbeing replaced; and responsive to a determination that a first node ofsaid updated sequence is different from a first node of said sequence,transmitting a fourth message pruning the network path from the firstnode of said sequence.
 13. The system according to claim 12, wherein,the at least one processor is further configured to: when the first nodeof said updated sequence is different from the first node of saidsequence, transmit a fifth message to the first node of said updatedsequence, the fifth message comprising the identification of themulticast source device and the identifier associated with the sequence.14. The system according to claim 13, wherein the fifth message is aprotocol-independent-multicast (PIM) join/prune message.
 15. The systemaccording to claim 12, wherein the second message is aprotocol-independent-multicast (PIM) join/prune message.
 16. The systemaccording to claim 12, wherein the first message is transmitted to aplurality of nodes in a network.
 17. The system according to claim 12,wherein the second message is transmitted to the first node of thesequence.